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Abstract 

The study and implementation of formal techniques to aid the design and implementation of Workflow Management 
Systems (WfMS) is still required. Using these techniques, we can provide this technology with automated reasoning 
capacities, which are required for the automated demonstration of the properties that will verify a given model. 
This paper develops a formalization of the workflow paradigm based on communication (speech-act theory) by 
using a temporal logic, namely, the Temporal Logic of Actions (TLA). This formalization provides the basic 
theoretical foundation for the automated demonstration of the properties of a workflow map, its simulation, and 
fine-tuning by managers. 
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1. Introduction 

Workflow concept has been received with great interest in the 
business world and in the area of software development. Work- 
flow technology and Workflow Management Systems (WfMS) 
are based on several disciplines: CSCW (Computer Supported 
Cooperative Work) and OIS (Office Information Systems) [1] 
are the main topics. Workflow includes a set of technological 
solutions that allow us to automate work processes previously de- 
scribed by a formal model (called workflow map). The modelling 
of business processes into a workflow map is aimed at obtaining 
total automation and optimization of such processes. 

Business processes reengineering, work simulation, organiza- 
tion modelling, resource management, and work automation are 
some aspects under the general issue of what is nowadays known 
as workflow technology [2] . 

The development of a workflow management system for an 
organization is a highly complex process. Therefore, the workflow 
map should be tested and validated before it is implemented; in 
other words, it should be analyzed prior to implementation. Most 
current workflow systems deal with this validation issue by using 
simulation modules that "execute" the model and examine the 
possible problems before it is truly "executed" and implemented 
in real life [3]. 

Although these simulation modules are very useful for the 
management team to detect problems in the business processes 
represented by the workflow, it would be advisable to find other 
more reliable methods. In other words, the model should allow 
and facilitate the automated demonstration of properties and char- 



acteristics. For example: will any workflow never be executed? 
Will this workflow ever be executed? Is the operation carried 
out with a specified time cost? Formal proving mechanisms will 
provide a practical solution to these kinds of problems [4], [5]. 

The use of formal methods based on logic in workflow mod- 
elling can establish an automated, formal, and robust reasoning 
mechanism that will successfully provide insight into these issues 
(conflict, deadlock, reacheability, reliability, satisfability) [6], [7]. 

However, the efficiency of visual modelling tools should be 
preserved and the introduction of new technology avoided. To 
achieve this we have to establish a direct and unambiguous rela- 
tionship between current workflow paradigms and temporal logic. 
In this way, and depending on the particular case, we will be able 
to use one or the other representational model: the visual/graphic 
model for design, and the formal model for automated handling 
and analysis [8], [9]. 

In this paper we aim at approaching workflow modelling in 
a different way. Our object is to make a formalization of the 
language/action paradigm [10], based on a extension of temporal 
logic. This extension is known as Temporal Logic of Actions 
(TLA) [11], and allows the easy modelling of transition states. 

Our approach is as follows: 

1. Specification of the workflow loop semantics (section 2.2). 

2. Translation of the workflow loop into a state transition 
diagram (section 2.4.1). 

3. The formalization in TLA of Searle's state transition dia- 
gram (section 4). 
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4. The formalization in TLA of workflow conections (section 
5). 

This paper is organized as follows: we begin with a descrip- 
tion of workflow, workflow management systems, and the mod- 
elling of workflow processes (sec. 2). In section 2.2 we analyze 
the basis of communication-based methodology ("speech-act"). 
In section 3 the TLA elements needed for the formalization are 
described. The core of this paper is (section 4 and 5), where the 
TLA formalization of the language/action paradigm is developed. 
The last section includes some relevant conclusions and future 
work. 

2. Workflow and Wf MS 

Workflow includes a set of technological solutions aimed at au- 
tomating work processes that are described in an explicit process 
model called the workflow map. Workflow has a wide range of 
possibilities as demonstrated by group support and the automation 
of organizational processes. 

In general terms we can define workflow as [7]: 

workflow is comprised by a set of activities dealing 
with the coordinated execution of multiple tasks de- 
veloped by different processing entities in order to 
reach a common objective 

This definition of workflow does not indicate the nature of the 
processing entity, which, therefore, can be a person, a computer, 
a machine, etc. [12], [13]. 

This technology is made tangible as information technology 
systems in the form of workflow management systems (WfMS). 
WfMS can be defined as [14]: 

"A system that defines, creates, and manages auto- 
matically the execution of workflow models by the 
use of one or more workflow engines in charge of 
interpreting process definitions (workflow maps), in- 
teracting with agents and, when required, invoking 
the use of information systems involved in the work" 

The workflow engine is in charge of coordinating the execu- 
tion of the workflow model, by determining the agents involved 
(whether humans or not), the data, and the applications required to 
carry out the workflow. The WfMS is made up of many modules, 
but this paper pays special attention to the simulation module 
which is used to test, via simulation, the workflow map before 
it is really implemented. Our aim is to propose a new reasoning 
workflow module that is able to analyze the model before its 
implementation. This reasoning procedure will establish the con- 
sistency of the model by demonstrating the properties it should 
satisfy [15]. 

To achieve this objective, the workflow map has to be ex- 
pressed in a way that allows such demonstrations. For this reason 
we will focus on demonstrating the possibility of translating work- 
flow technology into a logic tool. 



2.1 Modelling techniques for workflow processes 

Many authors agree on splitting workflow methodologies into 
two main categories [2]: 

• Activity-based methodology. These focus on modelling the 
activities that will take place during the development of the 
workflow [14]. 

• Communication-based methodologies. These stem from 
Searle's theory, known as "speech-acts" [16], [17]. 

Other techniques, like Petri Nets, Trigger Modelling, etc can 
be found in the literature [18]-[23], although other authors en- 
globe this techniques in the activity based group. 

As an example for good approach to time modelled, formal 
methods, Petri nets and in general modelling techniques that 
includes a formal method for achieve demonstrations can be 
found in [24]-[27] but these methods are centered in activity bases 
methodologies. Also we can introduce a new approach in the form 
of temporal logic formal methods into workflow technologies. 

As our case study falls into the communication-based cate- 
gory, to demonstrate that the formal methods can be applied. We 
will now describe the basic principles underlying this methodol- 
ogy- 

2.2 Communication-based methodologies 

Communication-based methodologies stem from the "Conversa- 
tion for Action" model developed by Medina-Mora, Winograd, 
and Flores [10], [28]. They view workflow as a sequence of 
conversations between a client and a server. In this section, the 
agents involved are described as the client requiring a service that 
will be developed or performed by the server . 

The communication previously described between client (Cli) 
and server (Svr) can be defined in four steps (figure 1): 

• Request/preparation. The client requests an action and 
establishes the criteria for completing it successfully. 

• Negotiation. The conditions for being satisfied with the 
work to be done are negotiated. 

• Development. The action is carried out by the server. 

• Acceptance. The workflow loop is finished by accepting 
the work under the terms of satisfaction established in the 
second step. 



Client 




er 



Figure 1. Workflow loop 



This model has two behaviors: 
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• internal behavior or micro-level: the workflow individual 
behavior. 

• external behavior or macro-level : the relations inter work- 
flows. 

2.3 External behavior. Workflow map 

A workflow map is the overall representation of all process into a 
organization. 

Each stage or step intra a workflow can be broken down into 
several workflows which will help to make them more specific. 
The set of subdivisions within the workflow loops is known as a 
Business Process Map (BPM). 




Figure 2. Example model 



At any phase we can connect workflows in three modes (see 
figure 2): (a) Sequential mode: like A and B workflows, (b) Con- 
ditional mode: like OP\ and OP2 that can be executed depending 
on the guard G. (c) Parallel model: like PARI and PARI. 

The workflow can be terminated at any time without being 
completed, which will raise an exception state where the task is 
not successfully finished. 

2.4 Internal behavior. Workflow loop and Searle's state 
transition diagram 

The language/action perspective on modelling is based on the 
"speech-act" theory outlined by Austin [29] and further developed 
by John Searle [16], [17]. Speech-acts occurring between two 
agents to carry out a given task are called "conversations" and 
they are the core framework for developing and performing the 
work. 

2.4.1 Conversation for action 

Conversation for action is the foundation of the theory upon which 
the workflow modelling studied in 2.2 is based. There are two 
speakers in this kind of conversation: one takes the role of client 
(Cli) requesting a service and the other the role of the server (Svr) 
that will carry out the task. 



In order to carry out the action, a sequence of request and 
commitment acts are established that will coordinate the action. 
The state diagram in figure 3 shows all possible transitions in 
a conversation for action. This diagrams corresponds with the 
representation at intra-workflow level. This level is how internally 
works an individual workflow. 

The original theory establishes two different possibilities for 
initiating the action: offering it or requesting it. 




Figure 3. State diagram of a workflow loop 



The diagram starts at state 1, opening the conversation, where 
Cli makes an initial request. This states triggers the transition to 
state 2, where the server Svr has three options: 

• Promise: the server commits itself to perform the work 
(state 3). 

• Refuse it/Decline: closes the conversation without perform- 
ing the work and transits to the final state 8. 

• Counteroffer: the terms for performing the work are nego- 
tiated (transition to state 6). 

If Svr initiates a counteroffer (transition from state 2 to 6), Cli 
has three options: 

• Accept the terms: Accept the counteroffer and initiate the 
work (transition to state 3, i.e., carrying out the work). 

• Counteroffer: New terms of satisfaction are proposed (back 
to state 2, work evaluation). 

• Refusing/Decline: The service is refused and we transit to 
the final state 8. 

The simplest path from the moment the task has been accepted 
is to successfully conclude it; i.e., going through the following 
transitions: 

• Petition: the action transits from 1 to 2. 

• Promise: the task is accepted (transition from 2 to 3). 

• Report: the accepted task is done (transition from 3 to 4). 

• Declare: if the product or service satisfies the clients' ex- 
pectations, there is a transition from 4 to 5. 
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Another path involves transitions requiring negotiation, i.e., 3 
and 4 transitions. From state 3: 

• Renege: Not performing the task accepted (from 3 to 7). 

• Withdraw: Cli automatically withdraws the request (state 
3 to 9). 

After Svr reporting that the work is concluded, several actions 
are still possible: 

• Declare: Cli declares the work has not been concluded 
satisfactorily, and Svr has to do it again (stage 4 to 3). 

• Withdraw: Cli automatically withdraws the petition (from 
state 4 to 9). 

This complex structure makes it possible for a system to 
computationally coordinate a task. 

3. Temporal Logic of Action 

Since the first temporal logic was proposed by Pnueli [6] many 
variants have been developed. In this paper, we make use of 
Temporal Logic of Actions (TLA) which allows us to model 
state transition diagrams in a relatively easy manner. Therefore, 
we now describe the basic principles described by Lamport [11] 
which are required to understand our work. 

TLA combines two types of logic: Action logic, used to 
represent relationships between states, and temporal logic, dealing 
with the reasoning involved in an infinite sequence of states. 

All TLA formulas are TRUE or FALSE in a behavior (= 
denotes equal to by definition). We define behavior a as an 
infinite sequence of states < so^i) s 2, ••• >. where each state s, 
has been assigned a corresponding variable. 

3.1 Elements of State Logic in TLA 

3.1.1 Variables 

An infinite number of variable names (e.g., x or y) and a value 
class set that can be assigned to the variables are assumed. These 
value classes include strings, numbers, sets, and functions. If x is 
a variable, [[x]] is the function that semantically maps the value 
of x in the states. Similarly, is the function of the value of 

x in the state s. 

3.1.2 State and predicate functions 

A state function is a non-Boolean expression built from variables, 
constants, and standard arithmetic operators. The semantics of 
[[/]], where / is a state function, consists of mapping states into 
values. To obtain the value of / in state s, we replace each variable 
x f off with [[*,•]] (j). 

Similarly, a predicate function or predicate P is a Boolean 
predicate. [[P]} is an application of the set of states in a Boolean 
value, s fulfills P iff [[Pj] (s) is equal to TRUE. 

3.1.3 Actions 

An action is a Boolean expression containing non-qualified primed 
variables (such as x 1 ), standard operators, and values. An action 
represents an atomic operation of the system. Semantically, an 
action A is true or false for a pair of states, and takes the primed 



variables belonging to the second state. If we take an old state 
s, a new state t, and an action A, we obtain [[A]](s,f), by first 
replacing each variable x with [[x\] (s) and each variable x' with 
[[x]] (t) to later evaluate the expression. It is said that the state pair 
(s,t) is a A-step iff [[A]](s,r) is equal to TRUE. 

3.1.4 Active action in a state and execution 

An action A is said to be active in a state s if there is a state / such 
that (s,t) is a A-step (equation 1). 

[[Enabled A]](s) = 3teo: [[A)](s,t) (1) 

An action A can be broken down into two logical formulae: 
G refers to the precondition, and B to the body of the action in 
itself (eq. 2). 

A = GAB (2) 

3.2 Elements of Temporal Logic in TLA 

In TLA, the behavior of a system is modeled as an infinite se- 
quence of states, where their basic elements are actions and tem- 
poral logic. The actions help us in a simple and specific way to 
control the potential next step. Temporal logic includes predicates, 
actions, logical operators, and temporal operators. 

In order to define the semantics of temporal formulae, we 
need to extend the semantic definition of the predicates whose 
value will be TRUE or FALSE in a given behavior. 

A behavior satisfies the predicate P iff (eq. 3) is satisfied in 
the first state. 

[[P}}(< sq, Si , **,->) =>[[*]](*)) (3) 

Similarly, a behavior satisfies the action A iff the first pair of 
states of the given behavior is an A-step (eq. 4). 

[\A]}(<s 0 ,s 1 ,s 2 ,--->) => [\A]](s 0 ,Si) (4) 

3.2.1 The Always Operator 

The operator □ (always) is the basic block of any temporal logic. 
Given a formula F, DF asserts that F is always TRUE (eq. 5): 

[[□F]](<io,5i,*2,-">)=Vn>0: [[F]}(< s n ,s n+u s n+2 , - ■ ■ >) 

(5) 

From equations 3 and 4 we define a behavior a that satisfies 
DP iff all the states of the behavior a satisfy P. Similarly, a 
behavior a satisfies DA iff all steps (.v,-,i, + i) are A-steps. 

3.2.2 The Operator Eventually 

All temporal formulae can be constructed with traditional opera- 
tors of first-order logic and the operator □. However, it is useful 
to define other operators such as 0 (eventually). The formula ()F 
asserts that F is eventually TRUE (eq. 6): 

[[<XF]](< s Ql s u i 2 , ■•■>) = 3n > 0 : [[F]](< s n ,s n+u s„ +2 , ■■■>) 

(6) 

In other words, (}F indicates that F is not always FALSE. 
Therefore: 

<XF = -iD-iF (7) 
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3.2.3 Validity 

A formulae F is valid iff it is satisfied for all behaviors (eq. 8). 
\=F = \/o eS°° : [[F]](a) (8) 
5°° denotes the set of all possible behaviors. 

3.2.4 Specification in TLA 

All previous definitions can be summed up in a single one to make 
a formal specification. A formal specification has the following 
general formula (eq. 9). 

n = Init A 0(Ai V A2 V • • • VA„) (9) 

A formula n is TRUE in a behavior iff its first state satisfies 
the predicate Init and each step at least satisfies an action A, . 

Actions in TLA are allowed only if the predicate Enabled is 
TRUE and the context can be expressed as in equation 10. 

[A] v =AVv' = v (10) 

This expression indicates that a new v-step is a step where 
either A is an A-step or the values of v do not change. Bear in 
mind that v is a set of important variables in the action to be 
executed. The action v' = v is usually called implicit stuttering 
action. 

Similarly, a non-stuttering execution can be defined: 

(A) v =AVvVv (11) 

That is to say, the execution is a v-step if the step changes the 
values of some of the variables indicated in v. 

3.2.5 Fairness Operators 

The fairness operators are in charge of ensuring that "nothing 
abnormal will happen". There are two types: weak fairness (WF) 
and strong fairness (SF) operators. 

Weak fairness. The weak fairness formula asserts that an 
action has to be infinitely executed frequently if it is continuously 
enabled for an infinitely long time. 

WF V (A) = □0(A> V V nO-iEnabled(A) v (12) 

Strong fairness. The strong fairness formula asserts that an ac- 
tion has to be infinitely executed frequently if it is often infinitely 
enabled. 

SF V (A) = 00(A),, V Q\3^Enabled(A) v (13) 
Similarly, the following theorem can be established: 

SF V (A) => WF V (A) (14) 

3.2.6 Formal specification of a system 

The formal specification of a system is as follows (eq. 15): 

n = Init A □[#],, A L (15) 



3.3 Formal approach to state diagram modelling 

Although it is possible to model any system with the structures 
previously described, it would be very useful in this case study 
to establish a formal mechanism for modelling state diagrams 
in TLA, since this will be the basis for formalizing the lan- 
guage/action paradigm. 

Lamport [30, 31] suggests the following formal approach 
to represent an action-predicate diagram. An action-predicate 
diagram is a diagram with a subset of nodes identified as initial 
nodes, where each node is labeled by a state predicate and every 
edge is labeled by an action. The following notation is used: 

• N: Set of nodes. 

• /: Set of initial nodes. 

• E[n): Set of edges originating at node n. 

• d(e): Destination node of edge e. 

• P n : The predicate labeling node n. 

• e e : The action labeling edge n. 

The formula A, representing the diagram is defined as follows: 

Init\ = 3n 6 / : P„ 
srf n = 3eeE{n):e e AP' d(e) 
A = /«(Y A AVneiV:D[P„^>4]y (16) 

If no specific label is attached to edge e, we take e e to be 
TRUE. When no set of initial nodes is explicitly specified, we 
take / to be N. s#„ is FALSE if no edges originate in node n. 

From this definition, we can now represent the diagram in 
TLA. 

4. Formalizing the language/action 
paradigm 

In order to formalize in TLA the state diagram introduced in 
section 2.4.1, its edges are labeled as ey as shown in figure 3 in 
order to follow the reference model later. 

As a prior step, we will define what is understood by work. 
Work Wk is a quadruple expressed in the equation 17 where: 

W k = {I,H,P,SC,V} (17) 

• /: Information needed to carry out the task. 

• H: Tools and methods needed for performing the task. 

• P: Person, role or agent with the capacity to perform the 
task. 

• SC: Terms of satisfaction for the work to be considered 
completed. 

• V: Set of state variables belonging to the workflow. 
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Each of these sub-variables is denoted as W^.I, W^.H, Wk-P, 
Wk.SC, Wfr.V, respectively, where Wk is the work element. 
The set of nodes in our diagram will be denoted by TV, , where 
is the number of the current state in the figure 3 (eq. 18). 

N= {Ni,N 2 ,N3,N4,N 5 ,N 6 ,N 7 ,N&,N g } (18) 

The initial state will be N\ , since communication starts there. 
Therefore: 

I = {Ni} (19) 

In this way, and bearing in mind the equation to be satisfied 
in the initial state, we have: 

Init A = 3neI:P» (20) 

Therefore, to complete the definition of the initial state we 
have to give meaning to P^ 1 , and this has to be done in the form 
of equation (eq. 21). 

PjVj = DetectTrigger(Type,Origine, Workflow) A 

Workflow = IDWF A Type £ T WFID A Origine = A 

(21) 

This predicate indicates that the workflow will start when an 
event coming from agent A is triggered and detected (DetectTrig- 
ger). From this point on, the agent A corresponds to the client 
Cli, and the event is a request for service identified as IDWF and 
corresponding to the workflow. 

Once the definition of the initial state N\ is completed, we 
can define the next state variables belonging to the set V. For 
simplicity sake, we will not follow the notation but rather the 
prefix V: 

• W k S: State of the work. 

• W fS: Current state of the workflow. 

• W fP: Current phase of the workflow. 

• Wj,: The variable representing the current work. 

• XW/t'. External work proposed by A (where A is the work- 
flow's client). 

• WfCli: Workflow client. 

• W fSvr. Workflow server. 

Once the workflow has started, there is a transition to state 
N2 through edge e\2- This edge assigns the variables shown in 
equation 22. 

e l2 = W' k = XW k A W f P' = "preparation" 
A W fS' = "active" 
A W k S' = "feasibility study" 
AWfCli' =A 

AW fSvr' = SelectAgent(OrgDB,B) (22) 

The workflow is still in progress and the task is assigned to the 
variable that records it within the system. The workflow IDWF 



is now instantiated and the requested external work is assigned to 
the execution model. This variable includes work XWk and the 
server B (Srv), which up to this point was unknown, as well as 
the initial terms of satisfaction XWk-SC. 

To assign or chose the server, we will use the function Selec- 
tAgent(OrgDB,B) that will select an agent from the organization 
among those fulfilling B type requirements (this function will 
have to access the knowledge base of the organization OrgDB). 

The workflow is now at state N%- In this state, the work B 
will perform has to be evaluated. The petition and result of such an 
evaluation will be represented by the function EvalWork(Wi r ,Agent) 

This function has two parameters, the work to be evaluated 
Wji and the agent in charge of such an evaluation. It also includes 
the option for the evaluating agent to modify or make proposals 
to change the response state. This response is obtained from 
Counteroffer^^, Agent) that returns a new offer of the work Wk 
from the agent. It is possible to return: Commitment, counteroffer, 
Decline or cancel. 

In this way P^ 2 will be in charge of carrying out the work 
evaluation. 

p Nl = S = EvalWork(Wjt,S) A 
(S = "Commitment" 

V S = "Counteroffer" 

V S = "Decline") (23) 

From state N2 we can advance through edges <?22, <?26 an d C28- 
Edge e28 leads to state N$, which is a final state of uncom- 
pleted termination of the workflow and comes from state 2 due to 
a decline of the offer (eq. 24). 

<?28 = S = "decline" 

AW fP' = "preparation" 
A W fS' = "abort" 

A W k S' = "Svr aborts" (24) 

Consequently, a predicate that will abort the execution of the 
workflow will be used in Ng. This will trigger an exception so that 
the system can take appropriate actions (eq. 25). This possibility 
is only open if the evaluation leads to "decline". 

P Nts = Exception W/(7£WF, "abort work", W k ) (25) 

In this state, the function Exception^/ is used. This triggers 
the exception of aborting the task, and goes back to TRUE when 
completed. 

The edge e26 corresponds to a counteroffer from B after the 
evaluation done in P^ 2 . In this way the assignation of state vari- 
ables is as shown in equation 26. 

^26 = S = "counteroffer" 

AW fP' = "negotiation" 
A W fS' = "active" 

A WkS' = "negotiation - Svr study the proposals" 
A Wk = Counteroffer^, W f Svr) 

(26) 
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In state N§ another evaluation is carried out, but this time is 
done by A (Pn 6 . This is shown in equation 27). 

P Ni = S = EvalWork(W k , W f Cli) A 
(S = "accepted" 

V S = "counteroffer" 

V S = "decline") (27) 

From state 6 we have three options: go to state 2 so that B 
reconsiders the offer made by the agent A (eq. 28), or it refuses 
it and goes to state 8, where the incomplete termination will call 
for exception (eq. 29). 

e 62 = S = "counteroffer" 

A IV fP 1 = "negotiation" 
A W fS' = "active" 

A WkS' = "negotiation - Cli study the proposals" 
A W k ' = ConunterOffer(Wfc, W/Cli) 

(28) 

<?68 = S = "decline" 

AWfP 1 = "negotiation" 
A W fS' = "aborted" 

A W k S' = "Cli refuse the work" (29) 

The third option open to A is to accept the current work 
W k , modified by B in this case, and transit to state N$ (eq. 30). 
Similarly, if the evaluation leads to B accepting the work, we 
could directly go from state N2 to A^, (eq. 31). 

<?63 = S = "accept" 

AW fP' = "development" 
A W fS' = "execution" 

A W k S' = "accepted" (30) 

<?23 = S = "accept" 

AW fP 1 = "development" 
A W fS' = "execution" 

A WkS 1 = "accepted" (31) 

Both equations are similar and do not have any effect on the 
variable Wk, which represents the current work, whether this is 
the original one or a counteroffer made by A or B (we assume 
that the equation 10 has been applied, i.e., if the work does not 
change, the variable preserves its value in the next state). 

In order to define P^ 3 we have to use some back-up functions 
that will enable us to express the semantics of this state. These 
functions are : 

• Trigger(f ; ,Wy): trigger t t to enable the sub-workflow Wr. 

• Completed(Wy): TRUE if Wf has been satisfactorily com- 
pleted. 

• Aborted(W/): TRUE if W f has terminated as abort. 



• Abort(X): TRUE if X aborts the workflow. 

Let us bear in mind that in this state all subtasks have to 
be run for the workflow to be completed. In addition, one of 
the following has to take place: a) all subtasks a, have to be 
completed; b) the incorrect termination of some subtasks has to 
be detected; or c) the client aborts the workflow. 

Let Wk-cii be each of the subtasks comprising the task of a 
workflow Wk, then P^ 3 is defined as (eq. 32 and 33): 

P N3 = V(a,£Wk,t,/t i = Tr 8 {a i ))Tiigger(t„W k .a l ) 

A{ExecutionPredicate) (32) 

ExecutionPredicate = DVa; £ W r / t/Completed(lV k- a i) 
VCBa, G W k /Aborted(W k -ai) 
\>Abon(W k Cli) (33) 

It is important to bear in mind that this equation can be applied 
to the states where the task to be carried out is evaluated, since 
such evaluation can give rise to a explosion of subtasks. 

Two options are possible: aborting the execution and going to 
state Nj or Ng depending on who aborted or going to evaluation 
state N4. These cases are expressed in equations 34, 35, and 36, 
respectively. 

e 3 9 = 3a,- eW k / 

{W k .ai.W f S = "aborted" 
AWk-cii-WkS = "Svr refuses the work") 
A(W fP' = "execution" 
A W fS' = "aborted" 

A W k S' = "Svr refuses the work") (34) 

e 3 7 = 3«; e W k / 

{W k .aj.W f S = "aborted" 

AW k-di-W kS = "Cli refuses the work") 

A(W fP' = "execution" 

A W fS' = "aborted" 

A W k S' = "Cli refuses the work") (35) 

e 3 4 = Vfl,- £ W k / 

(W k-Ui-W fS = "accepted" 
AWk-cii.WkS = "completed") 
A(W fP' = "evaluation" 
A W fS' = "active" 

A W k S' = "Cli's final evaluation") (36) 

State N4 consists in evaluating the final work (see equation 
37) using a predicate named EvalReport. 

Pn 4 = EvalReport(Wit,B) = "correct" 

V EvalReport(W,t,i?) = "incorrect" 

V Exception W f (IDWF, "abort work" , W k ) (37) 

If the work satisfies the terms, there is a transit to a final and 
successful state . On the other hand, if it does not, we go back 
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to the subtask execution state (this path is optional) and if it is 
aborted, it leads to Ng. These cases are expressed in equations 38, 
39, and 40. 

<?49 = W fP' = "evaluation" 
A W fS' = "aborted" 

A W k S' = "Cli rejects the work" (38) 

e 45 = WfP' = "Complete" 

A W f S' = "Completed" 

A WkS' = "work accepted for complete" (39) 

£43 = W fP' = "Execution" 
A W fS' = "Active" 

A WkS' = "work not accepted for complete : 
reexecute" (40) 

State N$ only has to send a completed signal (eq. 41). 

Pn 5 = ExceptionW^/ZWF, "Completed WF successful",!^) 

(41) 

Once these definitions are completed and the model equations 
are applied to formalize a state diagram (eq. 16) we obtain the 
formal representation. 

5. Formalizing the language/action 
paradigm as external behavior 

As a prior step, we will define what is understood by work. Work 
w is a quadruple expressed in the equation w = {I,H,P, SC. V} 
where: /: Information needed to carry out the task. H: Tools and 
methods needed to perform the task. P: Person, role or agent with 
the capacity to perform the task. SC: Terms of satisfaction for 
the work to be considered completed. V: Set of state variables 
belonging to the workflow. 

Each of these sub-variables is denoted as Wk-I, W^.H, Wk-P, 
Wk-SC, Wk-V, respectively, where Wk is the work element. 

Also we define a set of workflow attributes that can be used 
as control variables for its execution (these attributes are include 
in V): W k S: State of the work. WfS: Current state of the work- 
flow. W/P: Current phase of the workflow. Wk'. The variable 
representing the current work. XWk- External work proposed by 
A (where A is the workflow's client). W /Cli: Workflow client. 
W fSvr: Workflow server. 

At this point we can get the workflow behavior formalization. 
We use the example from figure 2 to illustrate how the main 
primitives formalize in TLA. We use the WfP and W/S workflow 
attributes for the specification. The control variable WfP that 
contains the actual worflow phase is as follows: 

WfP £ {"preparation" , "negotiation" , 
"development", "acceptance" ', "final"} 

WfS represents the internal status value for a workflow. This 
variable is equal to "finished" when the workflows is terminated. 



Also for the sub-workflows sequentiation into each phase 
we use the control attribute sec. This variable stores the actual 
execution position at each workflow phase. The sec type is an 
array that can be noted with Wf.sec if it has only one position or 
Wf.sec[\\iWf.sec\2\,...Wf.sec[n] that specifies multiples ways 
of execution. 

5.1 Workflow loop formalization 

With these elements we can formalize the case study in TLA. For 
the formalization we use the following notation: 

• *¥wf a formal specification of workflow WF. 

• WF the relationship with the following workflow state. 

• Init^wF initial condition for workflow execution. This 
condition is composed by InitwF (initial condition for work 
variables of workflow WF) and [nity or initial condition 
for WF control variables. Therefore Init^wF = InitwF A 
Inilxp. 

• WF{ phasejlame } the equation that defines the behavior at 
workflow level for each phase. W F{ negotiation } corresponds 
with the negotiation phase specification. If the specification 
does not exists its value will be WFx p y mejume \ = T and 
therefore always correct. 

• *¥wf, u i corresponds with the phase specification. 

" 1 [phase jwme) r r r 

• Ex(WFr phasejlame \) corresponds with the execution level 
specification of ^wf, , , ■ This is an atomic sub-workflow 

r \phasej\ame) 

and therefore equivalent at the definition level with the gen- 
eral formulae IVf- We use this term to nest specifications. 

• / corresponds with the set of variables used by workflow 
both control variables f <C ontml> an d work variables f<wF> 

if = f<control>^ f<WF>)- 

To begin with the WF specification we define the general 
formulae *¥wf (equation 42). 

*¥ WF = Init y ¥ WF AD[WF] f 
ASF(WF{ preparatio „ j ) 
ASF(WF{ negotiation y) 
ASF(WF {dn 

'elopment} ) 

ASF(WF {accep1 

mice \ ) (42) 

The initial state is the one at both control variables and work 
variables of WF (to simplify we do not use this type of variable). 
This state indicates that the workflow is in the "preparation" phase 
(equation 43). 

InififwF = Inity AlnitwF 

Inity = WfP = "preparation" (43) 

The workflow execution behavior consists in a sequential 
execution for each phase. Each phase executes its specification; 
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and when it finishes then the workflow transits to the next phase 
until the workflow has bee correctly completed (equation 44) . 



WF 



WWF, 



{preparation} 



VWF, 



{negotiation} 



VWF, 



{development} 



VWF, 



{acceptance} 



(44) 



Each specification can be found in equations 45, 46, 47 and 



48. 



{ P re par at ion } 



WF, 



{negotiation} 



WfP = "preparation'' 

" [preparation) 

WfP' = "negotiation" 
AUnchg <f _ {WfP}> 



WfP = "negotiation" 

^ ^{negotiation} 

WfP 1 = "development' 

AUnchg <f _ {WfP]> 



(45) 



(46) 



The execution is based on sub-workflow specifications A and 
B (equations 51, 52, 53 and . 



Ex(WF{ deve i opment } =A\JB 



A = 



KWF {developmen1 }.sec = "A" 

AWa A^/F {development} -Sec' = "B" 

AUnchg <f - WF{developmmtysec> 



B 



AWF 



{development} 



: "B" 



A^B A ^/F {development} - sec ' = " end " 

AUnchg <f - WF{da 



{development} ■ sec ^ > 



(51) 



(52) 



(53) 



5.3 Conditional task formalization 

The tasks OP1 and OP2 are executed depending precondition 
G at WF preparation phase. The equation 54 specifies how this 
phase works and the fairness section specifies that both OPl and 
OP2 will be executed eventually if infinitely often they are active 
for its execution. 



WF, 



{development} 



WF, 



{acceptance} 



WfP = "development" 

W F [development] 

WfP 1 = "acceptance" 
AUnchg <f _ {WfP}> 

WfP = "acceptance" 
A^wi 



{acceptance} 



W f P' 



"final" 
AUnchg <f _ {WfP]> 



(47) 



(48) 



WF, 



{preparation} 



IltitwF, ■ ! 

" * {preparation} 

A\3[Ex(WF {pl . epamtion} )] f 
A(WF(OPl) 
VWF(OP2)) 



We used G and the predicate InitwF, 



{preparation} 



(54) 
to decide about 



the execution for this sub-workflows (equation 55). 



Initwf, 



{prep.} 



(G^WF {prep} .sec-- 
V(^G-> 



"OPV 



5.2 Sequential tasks formalization 

Continuing with the example, we formalize tasks A and B where 
execution must be sequential. We use the sec attribute, which 
notes the actual execution sequence into each phase. 

The general equation begins with a development phase ^WF, ievelopment ^ 
(equation 49). 



WF, 



{prep.} 



.sec = "OPT 



(55) 



The execution definition, using the initialitation formulae, is 
(equations 56, 57 and 58): 



Ex(WF { 



^{development} 



{development} 



AD[Ex(WF^ developme „,j]f 

ASF (A) 

ASF(B) 



OPl 



preparation 



WF, 



}) 



(G^OPl)A 
(-.G OPT) 



(56) 



(49) 



The initial state variables has an effect on the sequential step 
(equation 50). 



{preparation)'""^ 

AVopi 

" F{ preparation} 

AUnchg <f - sec> 



Init^wF, 



{development} 



WF, 



{dev.}- 

AInitwF, 



"A" 



OPl 



WF, 



{preparation} ' 



{dev.} 



(50) 



We used operator A and V following Lamport's recommendation [31J 
Unchg is ' Unchanged operator' in TLA 



A^OPl 

WF, . , « 

rr * {preparation} ' Jf: 

AUnchg <f - sec> 



'OPV 



"fin" 



'OPT 



"fin" 



(57) 



(58) 
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5.4 Parallel execution formalization 

The PARI and PART, workflows are executed at the execution 
phase of workflow B. We use the *J/g formulae for the specifica- 
tion (equation 59). 



«P B = lnitm B A U[B] A SF(B) 



(59) 



The B specification follows the general schema that we used 
for WF (equation 60). 



Inity B 
B 



B.WfP = "preparation'' 
AInit BeS p 



B 



{preparation} 



Vfi 



{negotiation} 
{development} 



^ $ ' {acceptance} 



B {development} = ^B.W f P = "development" 

^ ^ ^ { development } 

AB.W/P f = "acceptance" 



(60) 



Finally we used the parallel composition to define B^ dtn , elopment j 
(equation 61). 



{development} 



(V PARI PARl) 



(61) 



6. Conclusions and Further work 



Workflow technology needs something else other than commer- 
cial workflow products to advance process automatization. The 
descriptive specification of workflow maps is very useful for man- 
agers - who have a description of business processes - and for 
development teams. However, we need more powerful tools to 
demonstrate workflow properties without the use of simulations. 

This paper introduces formal methods to carry out automated 
demonstrations of workflow properties. The formal method cho- 
sen is TLA. In order to prove the power of this logic, we have 
formalized the workflow loop of communication-based technolo- 
gies. Modelling the workflow structure has been addressed at a 
micro-level (internal behavior), i.e., at the workflow loop's inner 
operating level, and macro-level (external behavior), that is, the 
inter- workflows relations. 

We have shown that combining the use of traditional mod- 
elling methodologies and TLA makes possible the representation 
of workflow loops in a way that user-designers without expertise 
in logic can understand, and at the same time the model can be au- 
tomatically analyzed by demonstrating workflow properties such 
as consistency, time deadlines, and other desirable characteristics. 
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1. Introduction 

Wireless sensor networks are distributed systems with sensors 
used to monitor the environment in which it is being deployed. 
The application of sensor networks are vast and to mention few 
of them, military monitoring, healthcare monitoring, disaster and 
natural calamities monitoring, waste water monitoring, etc. These 
sensor nodes are resource constrained and always there is a neces- 
sity to construct novel algorithms and protocols that are energy 
aware in their operation. Researchers have proposed many pro- 
tocols in this direction, and use of computational intelligence is 
also one of the wide spread approach. There are many heuristic 
and meta heuristic algorithms used for designing the protocol. To 
name few of them swarm intelligence including ant colony opti- 
mization, bee colony optimization, particle swarm optimization, 
genetic algorithms, intelligent water drops, glow worm optimiza- 
tion, fire fly optimization, artificial immune systems, evolutionary 
algorithms, neural networks, so on. The usage of these computa- 
tional algorithms has lead to effective algorithm design in tackling 
various issues in wireless sensor networks like routing, security 
etc. The usage of firefly algorithms is the recent trend started 
from 2008 in wireless sensor networks and few related works are 
afore mentioned. Ming Xu et al. [1] proposed a work of using 
firefly algorithm for finding optimal route in underwater sensor 
networks by considering data correlation and their sampling rate 
in sensor nodes. Geoffrey Werner-Allen et al. [2] proposed a 
work of using Reachback Firefly Algorithm (RFA) for timing 
synchronization and delay compensation in Tiny-OS based motes. 
Song Cao et al. [3] proposed a method of using fire fly algorithm 



in finding optimal location for sensor nodes. Our recent work 
[4] proposes a bio-inpired clustering protocol based on Rhesus 
Macaque animal's social behavior. Bharathi et al. [5] propose 
a data aggregation scheme using elephants swarm intelligence. 
Bio-inspired computing is slowly gaining its momentum in the 
present WSN research. 

In this work, we present a methodology of using an algorithm 
inspired by the fireflies behavior for energy efficient clustering 
in wireless sensor networks, which serves to be a betterment 
on the basic LEACH protocol. The algorithm was simulated in 
MATLAB and results were compared with the LEACH, with 
respect to energy saving in the steady phase energy. 

The rest of the paper is organised as follows: section 2 deals 
with the basic LEACH protocol, section 3 discusses the fireflies 
behavior and algorithm, section 4 highlights the radio model 
considered for the calculation of energy consumption, section 5 
describes the proposed methodology, section 6 depicts the results 
and discussions associated with the protocol, finally the paper 
ends with the concluding remarks and the references. 

2. LEACH Protocol 

This section briefs out the LEACH (Low Energy Adaptive Clus- 
tering Hierarchy) protocol which was proposed by W.R. Heinzel- 
man et al. [6]. The protocol has two phases: set-up phase and 
steady-state phase. The protocol executes in rounds. Each round 
in LEACH has predetermined duration, through synchronized 
clocks, nodes know when each round starts. The setup consists 
of three steps. In Step 1 (advertisement step), nodes decide prob- 
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abilistically whether or not to become a Cluster Head (CH) for 
the current round (based on its remaining energy and a globally 
known desired percentage of CHs). Nodes that decide to do so 
broadcast a message {adv) advertising this fact, at a level that 
can be heard by everyone in the network. To avoid collision, a 
carrier sense multiple access scheme is used. In step 2 (cluster 
joining step), the remaining nodes pick a cluster to join based 
on the largest received signal strength of an adv message, and 
communicate their intention to join by sending a join_req (join 
request) message. Once the CHs receive all the join requests, step 
3 (confirmation step) starts with the CHs broadcasting a confirma- 
tion message that includes a time slot schedule to be used by their 
cluster members for communication during the steady-state phase. 
Given that all transmitters and receivers are calibrated, balanced 
and geographically distributed clusters should result. Once the 
the clusters are formed, the network moves on to the steady-state 
phase, where actual communication between sensor nodes and 
the Base Station (BS) takes place. Each node knows when is its 
turn to transmit (step 4), according to the time slot schedule. The 
CHs collect messages from all their respective cluster members, 
aggregate data, and send the result to the BS(step 5). The steady- 
state phase consists of multiple reporting cycles, and lasts much 
longer compared to the setup phase. 

3. Firefly algorithm 

The section highlights the behavioral aspects of fireflies and the 
firefly algorithm. 

3.1 Behavior of Fireflies 

There are around two thousand firefly species and most fireflies 
produce short and rhythmic flashes of light. The pattern of flashes 
is often unique for a particular species. The fundamental func- 
tions of such flashes are to attract mating partners and preys. 
Females respond to male's unique pattern of flashing within the 
same species. The light emitting from their body strictly obeys 
the inverse square law i.e. as the distance between two flies in- 
creases, the intensity of light decreases. The air absorbs light, 
which becomes weaker and weaker as the distance increases. The 
bioluminescence from the body of the fireflies is due to 'luciferin', 
which is a heterocyclic compound. 




Figure 1. Firefly (Scientific name: Photuris lucicrescens, 
courtesy: Wikipeclia.org). 

These behaviors of fireflies have lead to implementation of 
Firefly Algorithm (FA) that serves to be a metaheuristic algorithm 
under computational intelligence. 



3.2 Firefly Algorithm 

This section highlights the implementation of the fireflies' be- 
havior as described by Xin-She Yang [7]. The algorithm was 
formulated by assuming (i) All fireflies are unisexual, so that one 
firefly will be attracted to all other fireflies, (ii) Attractiveness is 
proportional to their brightness, and for any two fireflies, the less 
bright one will be attracted by (and thus move to) the brighter one; 
however, the brightness can decreases as the distance between 
them increases, (iii) If there are no fireflies brighter than a given 
firefly, it will move randomly. The brightness is associated with 
the objective function and the associated constraints along with 
the local activities carried out by the fireflies is represented by the 
following algorithm. 

Firefly Algorithm: Pseudo code 
Nomenclature 

- Ui= i' h firefly, i e [1,«]; 

- «= number of fireflies; 

- max_generation= count of the generations of fireflies (indicates 
iteration limit); 

- /,= Light Intensity magnitude of i th firefly depending on the 
objective function f(x); 

- y = absorption co-efficient; 

- r,j= distance between i th and f" fireflies. 

- f(xj) = objective function of i th firefly, which is dependent on 
its location Xj that is of d-dimension 



begin 

Generate initial population of fireflies m with location Xj , 
i = 1,2,3. ..«; 

Define objective function f(x), where x = (x[,X2, ...xj) T ; 
Generate initial population of fireflies x\ , i = l,2,3...n; 
Light intensity Ii of a firefly U{ at location Xj is determined 
byfixi)-. 

Define light absorption coefficient y; 
while (t < max -generation) do 
/*for all n- fireflies*/ 
for i=l:n do 

/*for all n- fireflies*/ 
for j=l:i do 

if (I j > I,) then 

move firefly i towards j in d-dimension 

else 
end 

end 

Attractiveness varies with the distance r via 
exp[—jr\; 

Evaluate new solutions and update light intensity; 
end 

end 

Rank the fireflies and find the current best; 
end 

Algorithm 1: Firefly Algorithm: Pseudo code. 

where d is the dimension of x in space that is also dependent on 
the context of the firefly, t is iteration variable. Intensity or the 
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brightness / is proportional to some objective function f(x) and 
the location update equation is given by (1). 



Xj = x, + j3exp[-yrfj] (xj -x,) + ae 



(1) 



where a is the step controlling parameter, e is the variable that 
brings about randomness, y is the attraction coefficient, j8 is 
the step size towards the better solution and xt is the location 
information of the observing entity. 

4. Radio Model 

The proposed methodology uses a classical radio model [6] and 
the sensor node is a transceiver. Hence, this radio model gives the 
energy consumed for the transmission and reception. The block 
diagram representation is shown in fig. 2. The radio model con- 
sists of transmitter and receiver equivalent of the nodes separated 
by the distance 'd' where E tx and E, x are the energy consumed 
in the transmitter and the receiver electronics. E amp is the energy 
consumed in the transmitter amplifier in general, and it depends 
on the type of propagation model chosen either free space or 
multipath with the acceptable bit error rate. We consider E/ s for 
free space propagation and E amp for multipath propagation as the 
energy consumed in the amplifier circuitry. The transmitter and 
the receiver electronics depends on digital coding, modulation, 
filtering and spreading of data. Additional to this there is an 
aggregation energy consumption of E agg per bit if the node is a 
cluster head. 



transmitter 
Electronics 
En 




li.in-.mHUr 
Amplifier 

1 imp 









Receher Electronics 
En 




Figure 2. Radio Model. 



4.1 Energy Consumption 

This section describes the energy consumed for communication. 



Packet transmission 

E, = (L P * E tx ) + (L P * E amp * d") 



(2) 



where Lp is the packet length in bits and n is the path loss 
component, which is 2 for free space and 4 for multipath propa- 
gation. 

Suppose a node transmits a packet. Each bit in a packet 
consumes E tx amount of transmitter electronics energy, E amp 
amount of amplifier energy. A packet of length Lp consumes an 
overall energy of E t . 



Packet reception 

E r = (L P *E rx ) (3) 

where Lp is the packet length in bits. 

Suppose a node receives a packet. Each bit in a packet con- 
sumes E lx amount of receiver electronics energy. A packet of 
length L p , consumes an overall energy of E t . 

5. Proposed Methodology 

This section deals with the modified firefly algorithm with the 
assumptions made for building this novel protocol. 

5.1 Assumptions 

1 . All the nodes can communicate with each other and with 
the BS directly. 

2. There is a single hop from ordinary node to CH and from 
CH to BS. 

3. All the nodes are static, where the algorithm run at a particu- 
lar time instant and update for next round, and all the nodes 
are location aware. They update their location information 
to the BS before entering into the set-up phase. 

4. 2-D space is considered for sensor node deployment. 

5.2 Description of protocol 

1. The BS broadcasts the percentage of CHs requirements for 
the entire network. Let this be P. Also it broadcasts the 
location information of all the nodes to the entire network. 

2. After receiving this information, all the nodes will calculate 
a random number and compare with T{n) given by the 
formula (4). 



T{n) = [ p i( l - p i rmod O^^ neG 

1 0, otherwise 



(4) 



If the random number is less than T{n) the node declares 
itself as the CH. G is the number of ordinary nodes eligible 
for becoming a CH in a particular round. 

3. First, the declared CHs start broadcasting the packet of 
interest. All the CHs learn about the ordinary nodes and 
other CHs in the plot. Then they broadcast the packet of 
interest by introducing the intensity value that it has calcu- 
lated using (5), which serves to be an objective function for 
all sensor nodes (fireflies in the proposed work). 



I(x)=I 0 /(l 



-yx?) 



(5) 



The minimum the value calculated by (5), large is the dis- 
tance between the CH and ordinary node. Io is the initial 
intensity value of all the nodes. Hence all the CHs store 
the maximum of the intensity values calculated with all the 
other ordinary nodes in the network belonging to a particu- 
lar round. The value of xt is calculated by using (6) as per 
the firefly algorithm [7]. 

x; = X[ + j5exp[—yrfj] (xj — xi) + a(rand — 0.5) (6) 
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where x\ is the location of the CH and xj is the location 
of the ordinary node and only the x co-ordinate is consid- 
ered for the intensity calculation as a reference. r l; is the 
distance between the CH and an ordinary node, calculated 
using Euclidean distance equation and e is (rand — 0.5). 
P, J and a are the parameters that are adjustable and rand 
provides the randomness in the equation (6). 

4. The ordinary nodes on receiving the packets from CHs 
calculate their intensity values using equations (5), (6) and 
(7), and store the maximum value of all the intensity values 
calculated with respect to all the CHs in the network. The 
ordinary nodes now compare their intensity values with 
all the other CHs intensity values and attach to a CH that 
is having more intensity value than their values, by send- 
ing a join request packet. This process leads to a cluster 
formation. 

5. After the formation of the clusters, the network enters to the 
steady state phase, where the nodes actually start transmit- 
ting their sensed values to the based station. This happens 
in rounds and usually a steady phase is accompanied by 
multiple rounds. 

6. After finishing the steady phase, the network enters into the 
set-up again and the process repeats. It is to be noticed that 
the intra cluster communication is accompanied by TDMA 
and CH- BS communication is accompanied by CDMA. 

6. Results and Discussions 

Table 1. Radio characteristics and other parameters chosen for 
simulation. 



Parameter 



Value 



Number of nodes 
Transmitter electronics, E tx 
Receiver electronics, E rx 

'-'amp 

Ef s 

Eagg 

Length of plot 
Width of plot 

L ; ,(packet transmitted from CH to BS) 
L c?) (packet transmitted from ordinary node 
to CH) 

Initial energy of the node 



100 

50 nJ/bit 
50 nJ/bit 
0.0013 pJ/bit 
10 pJ/bit 
5 nJ/bit 
100m 
100m 
6400bits 
200bits 

0.5J 



This section deals with the simulation results obtained for the 
proposed method. The simulations were carried out in PC with 
Intel 15 processor, and windows operating system. MATLAB 
2009 is used as the simulating platform. 

Uniform distribution was used to randomly distribute the 
nodes in 100m x 100m plot. The BS was located at (50, 175) 
position. The deployment of sensor nodes is shown in the fig. 
3. Table 1 shows various parameters set for the protocol. The 
percentage of CHs requirement from the BS was set to 10% for 



100 i 



■ 

t 



* • B * • » 



0 '0 20 X 



100 



50 h it m 



Figure 3. Network deployment. 
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Figure 4. Residual energy in the network for 1000 rounds. 



all the rounds. The protocol was executed for one cycle of steady- 
state phase in each round, with the assumption of all the nodes 
having some data to transmit. 

The parameters of the firefly algorithm were adjusted as fol- 
low: a = 2, P = 2, 7 = 2, Iq = 5 and rand used was rand() 
function of MATLAB which offers an uniform distribution. 

The simulation results are shown in fig.4 and fig. 5. Graph in 
fig.4 shows that, as the simulations reaches approximately 1000'' 1 
round, the energy consumed by Basic-LEACH was observed to 
be more than the novel Fire-LEACH. 

Fig. 5 shows that as the simulations reaches approximately 
1000'' 1 round, the number of dead nodes in the network increases 
in the Basic-LEACH compared to the Fire-LEACH. 

It was observed from graphs of fig. 6, fig. 7 and fig. 8 that 
variation in the constants y, a and j6, there were shifts in the 
energy curves. Hence by prior adjustments of optimal values for 
these constants results in better reduction in the overall network 
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Figure 5. . Number of dead Nodes in the Network for 1000 
rounds. 
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Figure 7. Variations in the network residual energy for different 
values of a (1000 rounds). 
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Figure 6. Variations in the network residual energy for different Figure 8. Variations in the network residual energy for different 
values of attraction factor y ( 1000 rounds). values of /3 ( 1000 rounds). 



energy consumption. A similar reason can be given for even the 
node survival rate graphs shown in fig. 9, fig. 10 and fig.l 1. 

For the simulations only the steady phase energy was consid- 
ered neglecting the set-up phase energy. It has to be noted that 
in all the clustering protocols, there is considerable amount of 
energy consumption in the set-up phase. 

7. Conclusions 

The work proposed in this paper demonstrates the use of com- 
putational intelligence in improving network performance by 
reducing the overall network energy consumption and increasing 
the node survival rate. The proposed methodology was applied to 



the basic LEACH protocol and simulation results prove that the 
algorithm enhances the energy efficiency thereby increasing the 
node survival rate and provides a proof that the method can be 
implemented in the future networks with ease. 
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